Management systems allow users to manage target functionality. “Target functionality” can comprise an application or applications, e.g., as implemented by one or more computer systems, which are the “target” of the management system's management operations. One well known management system uses the Microsoft Management Console (MMC), provided by Microsoft Corporation of Redmond, Wash. Detailed information regarding the MMC management system is provided by a number of sources, such as Microsoft Corporation's MSDN online library site.
Broadly stated, a typical management system provides a container (a management console) which binds together a collection of tools for managing different aspects of target functionality. Accordingly, the characteristics of a management system may differ depending on the types of tools that the management system incorporates. In a typical role, the management system allows a user to query the target functionality to extract management information from the target functionality. The management system then presents the retrieved management information to the user and allows the user to interact with the management information. For instance, the user can use the management system to manage the configuration of some aspect of the target functionality. In this role, the management system queries the target functionality to extract configuration information from one or more configuration databases maintained by the target functionality. The management system then allows the user to perform various actions that affect the configuration information, which thereby affects the configuration of the target functionality.
FIG. 1 shows salient features of a known system 100 that uses a management system 102 to govern the operation of target functionality 104. As described above, the management system 102 provides a shell or container which aggregates different tools. Code resources 106 provide the functionality which implements the management system 102.
The management system 102 provides an integrated user interface presentation that allows a user 108 to conveniently interact with the management system 102's tools. Namely, the user 108 can interact with the management system 102 via a series of user interface presentations 110 provided on a display device 112 (such as a CRT device, an LCD device, etc.), in conjunction with an input mechanism 114 (such as a keyboard, a touch screen, a mouse-type pointing device, a joystick, and so forth).
The target functionality 104 with which the management system 102 interacts can be implemented using a standalone computer unit (e.g., a personal computer workstation), a system that comprises plural computer units and associated databases (such as a server system and associated databases), or some other functionality. In any event, the target functionality 104 can comprise one or more management stores 116. The management stores 116 store management information which governs the operation of one or more applications 118 implemented by the target functionality 104. For example, the management information can correspond to configuration information that pertains to various settings, security-related information, etc. that govern the operation of one or more applications 118.
In operation, the management system 102 functions by: (1) querying the management stores 116 to determine the management information (e.g., configuration information) stored therein; (2) retrieving the management information and presenting it to the user 108 via the one or more user interface presentations 110; and (3) allowing the user 108 to interact with the management information (which enables the user 108 to modify the management information stored in the management stores 116). As to the first of these enumerated tasks, the system 100 provides retrieval functionality 120 which allows the user 108 to query the management stores 116 and extract information from these stores 116. In an exemplary environment that uses a Windows™ operating system, the retrieval functionality 120 can rely on Windows™ Management Instrumentation (WMI) technology. Alternatively, or in addition, the retrieval functionality 120 can rely on, in whole or in part, SQL-related technology, Active Directory technology, and so forth.
The user interface presentations 110 provided by the management system 102 can use different strategies for presenting management information to the user 108 and for allowing the user 108 to interact with that information. FIGS. 2-4 provide representative examples of user interface presentations 110 based on the UI paradigm employed by Microsoft Corporation's MMC management console. Referring first to FIG. 2, a main user interface presentation 200 includes two panes. A so-called scope pane 202 establishes the “scope of management” of the management system. Namely, the scope specifies the boundaries that define where the configuration information originates and the aspects of the system that are managed by changes in the configuration information. For example, a management system directed to the configuration of an operating system might specify a root of “System,” and, the System scope can allow a user to configure a disk (defining another scope in its own right), and so forth. FIG. 2 shows that the scope pane 202 includes a plurality of nodes arranged in a tree-like hierarchical relationship. The topmost node in the tree defines a root node. Nodes that depend on the root node define child nodes. Based on this paradigm, the user 108 can organize tools into categories based on the commonality of different groups of tools, and so forth. The management system 102 can represent each node in the scope pane 202 using textual information and/or an image icon.
The user 108 can expand any parent node in the tree (represented by a conventional plus sign “+”) to reveal its child node contents. To perform this function, the management system 102 may access information to determine the child nodes associated with a parent node selected by the user 108. In this particular case, the user 108 has expanded an “event viewer” tool node 206, to reveal different categories of events that can be perused by the user 108 (e.g., application events, security events, and system events).
A result pane 204 (also commonly referred to as a detail pane) provides more detail regarding an identified node in the scope pane 202. For example, in the example of FIG. 2, the user 108 has selected a node 208 corresponding to a tool that provides system events. Upon selecting this node 208, the management system 102 responds by presenting detail pertinent to this node 208, which, in this case, corresponds to plurality of system events. The table-type or list-type presentation shown in the result pane 204 is merely one illustrative example; other tools can invoke other kinds of user interface presentations to reveal management information.
FIG. 3 shows one mechanism that allows the user 108 to interact with the main user interface presentation 200. Namely, the management system 102 can be configured such that, when the user 108 activates a particular node, the management system 102 presents a context menu associated with the activated node. In the example of FIG. 3, the user 108 has right-clicked on the system node 208. This prompts the management system 102 to present an associated context menu 302. As shown, the context menu 302 presents a number of options which allow the user 108 to interact with the management system 102. Selection of one or more options in the context menu 302 may invoke respective submenus, as in the case where the user 108 selects a “view” option, which prompts the management system 102 to present a submenu 304 relating to the view topic. In the context of a configuration-related application, the context menu options can permit the user 108 to define or modify configuration information which will govern the operation of the target functionality 104.
The main user interface presentation 200 may also serve as a portal for several other kinds of supplemental user interface presentations that work in conjunction with the main user interface presentation 200. Consider the example of FIG. 4. Here, the user 108 has clicked on a particular entry 402 in the result pane 204. In this particular example, the user 108's action prompts the management system 102 to display a supplemental user interface presentation 404 that provides more information regarding the selected entry 404. The particular type of the supplemental user interface presentation 404 shown in FIG. 4 is merely illustrative. Other management systems can invoke user interface presentations having multiple tabbed pages (where the user 108 can select any page in any order in one of these presentations by activating its associated tab). Still other management systems can invoke wizard-type user interface presentation (where the user 108 is restricted to interacting with the pages of one of these presentations in a predefined order). Moreover, the illustrative supplemental user interface presentation 404 shown in FIG. 4 merely displays information regarding the selected entry 402. But other supplemental user interface presentations (not shown) can allow the user 108 to enter information into the management system 102, e.g., via one or more appropriately configured dialog boxes. In the context of a configuration application, the user 108 can use these supplemental user interface presentations to enter information used to modify information stored in a configuration database. To facilitate discussion, all such supplemental user interface presentations are referred to herein as “dialog-related user interface presentations.”
Returning to FIG. 1, as mentioned, the management system 102 can rely on a collection of resources 106 to provide the logic which implements different management system applications. In actual practice, a programmer can go about developing code for a particular management system application by separately providing code that implements each node of the application. For each node, this code can implement data retrieval tasks, data presentation tasks, user interaction-related tasks, and so forth. A programmer can create other resources to provide the type of dialog-related user interface presentations shown in FIG. 4.
In conventional practice, the code developed to implement different management system applications represents independent logic. For example, at runtime, a management system application X can be implemented by a first collection of code, while a management system application Y can be implemented by a second collection of code, where the first collection of code is independent and autonomous from the second collection of code. As in any programming context, it is true that a programmer can rely on common building blocks to develop different applications. But the programmer nevertheless goes about the task of developing the code for each application on an individual basis, manually integrating and adapting any common code modules into each application on an ad hoc basis so that these modules properly interact with the rest of the application.
The same design philosophy applies to the creation of dialog-related user interface presentations. Different dialog-related user interface presentations (such as different wizard-type presentations) represent independent and autonomous UI resources. A programmer may draw from common building blocks in constructing dialog-related user interface presentations. Nevertheless, the programmer otherwise goes about the task of developing each dialog-related user interface presentation on an individual basis in the manner described above, e.g., by manually integrating and adapting common UI resources into each unique dialog-related presentation on an ad hoc basis.
As recognized by the present inventors, the above-described approach to writing code and developing dialog-related user interface presentations has several drawbacks. First, the above-described approach is time-consuming, perhaps requiring a week or more to write the code for a single node. Second, the above-described approach may provide management system code and associated dialog-related user interface presentations which lack uniformity from one application to the next; this, in turn, may make it more difficult to understand the code, and hence to debug and/or upgrade it. Third, the above-described approach implements a management system application at runtime using a large amount of code that is specifically adapted to work with only that application (there being no sharing of code among different management system applications). This results in various storage-related and performance-related inefficiencies. The above-described approach to developing dialog-related user interface presentations has similar drawbacks.
For at least the above-identified reasons, there is an exemplary need for more satisfactory strategies for building management systems, including dialog-related user interface presentations used to interact with the management systems (as well as other applications).